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Abstract 


The computation of one or a set of Traffic Engineering Label Switched 
Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and 
Generalized MPLS (GMPLS) networks is subject to a set of one or more 
specific optimization criteria, referred to as objective functions 
(e.g., minimum cost path, widest path, etc.). 


In the Path Computation Element (PCE) architecture, a Path 
Computation Client (PCC) may want a path to be computed for one or 
more TE LSPs according to a specific objective function. Thus, the 
PCC needs to instruct the PCE to use the correct objective function. 
Furthermore, it is possible that not all PCEs support the same set of 
objective functions; therefore, it is useful for the PCC to be able 
to automatically discover the set of objective functions supported by 
each PCE. 


This document defines extensions to the PCE communication Protocol 
(PCEP) to allow a PCE to indicate the set of objective functions it 
supports. Extensions are also defined so that a PCC can indicate in 
a path computation request the required objective function, and a PCE 
can report in a path computation reply the objective function that 
was used for path computation. 


This document defines objective function code types for six objective 
functions previously listed in the PCE requirements work, and 
provides the definition of four new metric types that apply to a set 
of synchronized requests. 
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1. Introduction 


The Path Computation Element-based network architecture [RFC4655] 
defines a Path Computation Element (PCE) as an entity capable of 
computing the paths of Traffic Engineered Label Switched Paths (TE 
LSPs) based on a network graph and of applying computational 
constraints. A PCE services path computation requests that are sent 
by Path Computation Clients (PCC). 
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The PCE communication Protocol (PCEP), defined in [RFC5440], allows 
for communication between a PCC and a PCE or between two PCEs, in 
compliance with requirements and guidelines set forth in [RFC4657]. 
Such interactions include path computation requests and path 
computation replies. 


The computation of one or a set of TE LSPs is subject to a set of one 


or more optimization criteria, called an objective function. An 
objective function is used by the PCE when it computes a path or a 
set of paths in order to select the "best" candidate paths. There is 


a variety of objective functions: an objective function could apply 
either to a set of non-synchronized path computation requests, or to 
a set of synchronized path computation requests. In the former case, 
the objective function refers to an individual path computation 
request (e.g., computation of the shortest constrained path where the 
metric is the IGP metric, computation of the least loaded constrained 
path, etc.). Conversely, in the latter case, the objective function 
refers to a set of path computation requests the computation of which 
is synchronized (e.g., minimize the aggregate bandwidth consumption 
of all LSPs, minimize the sum of the delays for two diverse paths or 
of the delta between those delays, etc.). Moreover, some objective 
functions relate to the optimization of a single metric and others to 
the optimization of a set of metrics (organized in a hierarchical 
manner, using a weighted function, etc.). 


As spelled out in [RFC4674], it may be useful for a PCC to discover 
the set of objective functions supported by a PCE. Furthermore, 
[RFC4657] requires the ability for a PCC to indicate in a path 
computation request a required/desired objective function, as well as 
optional function parameters. 


For these purposes, this document extends the PCE communication 
Protocol (PCEP). It defines PCEP extensions that allow a PCE to 
advertise a list of supported objective functions, as well as 
extensions to carry the objective function in PCEP request and reply 
messages. It complements the PCEP base specification [RFC5440]. 


Note that OSPF- and IS-IS-based PCE discovery mechanisms are defined 
in [RFC5088] and [RFC5089]. These mechanisms are dedicated to the 
discovery of a few generic parameters, while more detailed PCE 
parameters should be discovered using the PCE communication Protocol. 
Objective functions are in this second category; thus, the objective 
function discovery procedure is handled by PCEP. 


A new PCEP TLV, named the OF-List TLV, is defined in Section 2. The 
OF-List TLV is carried in the PCEP OPEN object and allows a PCE to 
list, during PCEP session-setup phase, the objective functions that 
it supports. 
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A new PCEP object, the OF object, is defined in Section 3. The OF 
object is carried within a PCReq (Path Computation Request) message 
to indicate the required/desired objective function to be applied by 
a PCE, or in a PCRep (Path Computation Reply) message to indicate the 
objective function that was used for path computation. 


Six mandatory objective functions that must be supported by PCEP are 
listed in [RFC4657]. This document provides a definition of these 
six mandatory objective functions. Additional objective functions 
may be defined in other documents. Note that additional objective 
functions are defined for the PCE Global Concurrent Optimization 
(GCO) application, in [PCE-GCO]. 


This document also provides the definition of four new metric types 
that apply to a set of synchronized requests. 


1.1. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOI", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


1.2. Terminology 
LSR: Label Switching Router. 


OF: Objective Function. A set of one or more optimization 
criteria used for the computation of a single path (e.g., 
path cost minimization) or for the synchronized computation 
of a set of paths (e.g., aggregate bandwidth consumption 
minimization, etc.). 


PEG: Path Computation Client. Any client application requesting a 
path computation to be performed by a Path Computation 
Element. 

PCE: Path Computation Element. An entity (component, application, 


or network node) that is capable of computing a network path 
or route based on a network graph and of applying 
computational constraints. 


PCEP: Path Computation Element communication Protocol. 


TE LSP: Traffic Engineered Label Switched Path. 
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3. Message Formats 


Message formats in this document are expressed using Reduced BNF as 
used in [RFC5440] and defined in [RFC5511]. 


Discovery of PCE Objective Functions 


This section defines PCEP extensions (see [RFC5440]) so as to support 
the advertisement of the objective functions supported by a PCE. 


A new PCEP OF-List (Objective Function list) TLV is defined. The 
PCEP OF-List TLV is carried within an OPEN object. This way, during 
PCEP session-setup phase, a PCE can advertise to a PCEP peer the list 
of objective functions it supports. 


1. OF-List TLV 


The PCEP OF-List TLV is optional. It MAY be carried within an OPEN 
object sent by a PCE in an Open message to a PCEP peer so as to 
indicate the list of supported objective functions. 


The OF-List TLV format is compliant with the PCEP TLV format defined 
in [RFC5440]. That is, the TLV is composed of 2 octets for the type, 
2 octets specifying the TLV length, and a Value field. The Length 
field defines the length of the value portion in octets. The TLV is 
padded to 4-octet alignment, and padding is not included in the 
Length field (e.g., a 3-octet value would have a length of three, but 
the total size of the TLV would be eight octets). 


The PCEP OF-List TLV has the following format: 


TYPE: 4 

LENGTH: N * 2 (where N is the number of objective functions) 

VALUE: list of 2-byte objective function code points, identifying 
the objective functions supported by the sender of the Open 
message. 

0 al 2 3 


TA dE Gr NOT DA RG O LAA BG 7 8 OO 
dh os es D Ds D Ds Ds 
| OF Code #1 | OF Code #2 | 
$ hh RR dd de de e de dd dd dd 4 4 4 4 4 + + +++ +++ +++ 
// // 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| OF Code #N padding | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
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OF Code (2 bytes): Objective Function code point identifier. IANA 
manages the "PCE Objective Function" code point registry (see Section 
6). 


2.2. Elements of Procedure 


A PCE MAY include an OF-List TLV within an OPEN object in an Open 
message sent to a PCEP peer in order to advertise a set of one or 
more objective functions. The OF-List TLV MUST NOT appear more than 
once in an OPEN object. If it appears more than once, the PCEP 
session MUST be rejected with error type 1 and error value 1 (PCEP 
session establishment failure / Reception of an invalid Open 
message). The absence of the OF-List TLV in an OPEN object MUST be 
interpreted as an absence of information on the list of supported 
objective functions by the PCE. 


As specified in [RFC5440], a PCEP peer that does not recognize the 
OF-List TLV will silently ignore it. 


3. Objective Function in PCEP Path Computation Request and Reply 
Messages 


This section defines PCEP extensions [RFC5440] so as to support the 
communication of objective functions in PCEP path computation request 
and reply messages. A new PCEP OF (Objective Function) object is 
defined, to be carried within a PCReq message in order for the PCC to 
indicate the required/desired objective function. 


The PCEP OF object may also be carried within a PCRep message in 
order for the PCE to indicate the objective function that was used by 
the PCE. 


A new flag is defined in the RP (Request Parameters) object. The 
flag is used in a PCReq message to indicate that the PCE MUST include 
an OF object in the PCRep message to indicate the objective function 
that was used during path computation. 


Also, new PCEP error types and values are defined. 

3.1. OF Object 
The PCEP OF (Objective Function) object is optional. It MAY be 
carried within a PCReq message so as to indicate the desired/required 
objective function to be applied by the PCE during path computation 


or within a PCRep message so as to indicate the objective function 
that was used by the PCE during path computation. 
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The OF object format is compliant with the PCEP object format defined 
in [RFC5440]. 


The OF Object-Class is 21. 
The OF Object-Type is 1. 


The format of the OF object body is: 


0 1 2 3 

Où LL, 2 3. 4 Dr AT 289 OLR A SB Er HUB AOL 22:58; 40506 TAE 90; LL 
dh A A A O O A O +++ 
| OF Code | Reserved | 
+-+-+-+-+-+-+-+-+-+-+- ++ 
// Optional TLV (s) // 
+ 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


OF Code (2 bytes): The identifier of the objective function. IANA 
manages the "PCE Objective Function" code point registry (see Section 
6). 


Reserved (2 bytes): This field MUST be set to zero on transmission 
and MUST be ignored on receipt. 


Optional TLVs may be defined in the future so as to encode objective 
function parameters. 


3.1.1. Elements of Procedure 


To request the use of a specific objective function by the PCE, a PCC 
includes an OF object in the PCReq message. 


[RFC5440] specifies a bit flag, referred to as the P bit, carried in 
the common PCEP object header. The P bit is set by a PCC to mandate 
that a PCE must take the information carried in the object into 
account during the path computation. 


If the P bit is set in the OF object, the objective function is 
mandatory (required objective function) and the PCE MUST use the 
objective function during path computation. If the P bit is clear in 
the OF object, the objective function is optional (desired objective 
function) and the PCE SHOULD apply the function if it is supported 
but MAY choose to apply a different objective function, according to 
local capabilities and policies. 
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On receipt of a PCReq message with an OF object, a PCE MUST proceed 
as follows: 


- If the OF object is unknown/unsupported, the PCE MUST follow 
procedures defined in [RFC5440]. That is, if the P bit is set, the 
PCE sends a PCErr message with error type 3 or 4 (Unknown / Not 
supported object) and error value 1 or 2 (unknown / unsupported 
object class / object type), and the related path computation 
request MUST be discarded. If the P bit is cleared, the PCE is 
free to ignore the object. 


— If the objective function is unknown/unsupported and the P bit is 
set, the PCE MUST send a PCErr message with error type 3 or 4 
(Unknown / Not supported object) and error value 4 
(Unrecognized/Unsupported parameter), and the related path 
computation request MUST be discarded. 


- If the objective function is unknown/unsupported and the P bit is 
cleared, the PCE SHOULD apply another (default) objective function. 


— If the objective function is supported but policy does not permit 
applying it and if the P bit is set, the PCE MUST send a PCErr 
message with the PCEP error type "policy-violation" (type 5) and a 
new error value, "objective function not allowed", which is defined 
in this document. 


— If the objective function is supported but policy does not allow 
applying it and if the P bit is cleared, the PCE SHOULD apply 
another (default) objective function. 


— If the objective function is supported and policy allows applying 
it and if the P bit is set, the PCE MUST apply the requested 
objective function. Otherwise, if the P bit is cleared, the PCE is 
free to apply any other objective function. 


The default objective function may be locally configured. 

3.2. Carrying The OF Object In a PCEP Message 
The OF object MAY be carried within a PCReq message. If an objective 
function is to be applied to a set of synchronized path computation 
requests, the OF object MUST be carried just after the corresponding 


SVEC (Synchronization VECtor) object and MUST NOT be repeated for 
each elementary request. 
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Similarly, if a metric is to be applied to a set of synchronized 
requests, the METRIC object MUST follow the SVEC object and MUST NOT 
be repeated for each elementary request. Note that metrics applied 
to a set of synchronized requests are defined in Section 5. 


An OF object specifying an objective function that applies to an 
individual path computation request (non-synchronized case) MUST 
follow the RP object for which it applies. 


The format of the PCReq message is updated as follows. Please see 
Appendix A for a full set of RBNF fragments defined in this document 
and the necessary code license. 


<PCReq Message> ::= <Common Header> 
[<svec-list>] 
<request-list> 


where: 
<svec-list> 


<SVEC> 

[<OF>] 
[<metric-list>] 
[<svec-list>] 


<request-list> ::= <request> [<request-list>] 


<request> ::= <RP> 
<END-POINTS> 
[<LSPA>] 
[<BANDWIDTH>] 
[<metric-list>] 
[<OF>] 
[<RRO> [<BANDWIDTH>] ] 
[<IRO>] 
[<LOAD-BALANCING>] 


and where: 
<metric-list> ::= <METRIC>[<metric-list>] 


The OF object MAY be carried within a PCRep message to indicate the 
objective function used by the PCE during path computation. 


When the PCE wants to indicate to the PCC the objective function that 
was used for the synchronized computation of a set of paths, the 
PCRep message MUST include the corresponding SVEC object directly 
followed by the OF object, which MUST NOT be repeated for each 
elementary request. If a metric is applicable to the set of paths, 
the METRIC object MUST directly follow the SVEC object and MUST NOT 
be repeated for each elementary request. 
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An OF object specifying an objective function used for an individual 
path computation (non-synchronized case) MUST follow the RP object 
for which it applies. 


The format of the PCRep message is updated as follows. Please see 
Appendix À for a full set of RBNF fragments defined in this document 
and the necessary code license. 


<PCRep Message> ::= <Common Header> 
[<svec-list>] 
<response-list> 


where: 
<svec-list> ::= <SVEC> 
[<OF>] 
[<metric-list>] 
[<svec-list>] 
<response-list> ::= <response> [<response-list>] 
<response> ::= <RP> 
[<NO-PATH>] 
[<attribute-list>] 
[<path-list>] 
<path-list> ::= <path> [<path-list>] 
<path> ::= <ERO> 


<attribute-list> 


and where: 


<attribute-list> ::= [<OF>] 
[<LSPA>] 
[<BANDWIDTH>] 
[<metric-list>] 
[<IRO>] 


<metric-list> ::= <METRIC> [<metric-list>] 


Note: The OF object MAY be associated to a negative reply, i.e., a 
reply with a NO-PATH object. 
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3.3. New RP Object Flag 


In some cases, where no objective function is specified in the 
request or an optional objective function is desired (P flag cleared 
in the OF object common header) but the PCE does not follow the 
request, the PCC may desire to know the objective function that was 
used by the PCE during path computation. To that end, a new flag is 
defined in the RP object, named the OF flag, allowing a PCC to 
request for the inclusion in the path computation reply of the 
objective function that was used by the PCE during path computation. 


The following new bit flag of the RP object is defined: 


The Supply OF on response flag (bit number 24). When set in a PCReq 
message, this indicates that the PCE MUST provide the applied 
objective function (should a path satisfying the constraints be 
found) in the PCRep message. When set in a PCRep message, this 
indicates that the objective function that was used during path 
computation is included. 


3.3.1. Elements Of Procedure 


If the PCC wants to know the objective function used by the PCE 
during path computation for a given request, it sets the OF flag in 
the RP object. 


On receipt of a PCReq message with the OF flag in the RP object set, 
the PCE proceeds as follows: 


— If policy permits, it MUST include in the PCRep message an OF 
object indicating the objective function it used during path 
computation. 


— If policy does not permit, it MUST send a PCErr message with the 
PCEP error code "policy-violation" (type 5) and a new error value, 
"objective function indication not allowed", which is defined in 
this document. 


Note that a legacy PCE might not recognize the OF flag in the RP 
object. According to the definition of the Flags field for the RP 
object (Section 7.4.1 of [RFC5440]), the legacy PCE will ignore the 
unknown flag, resulting in it sending a PCRep that does not contain 
an OF object. In this case, the PCC’s behavior is an implementation 
choice. The PCC might: 


— Discard the PCRep because it really wanted the OF object returned. 


— Accept the PCRep without the knowledge of the OF that was applied. 
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Note also that these procedures can give rise to the situation where 
a PCC receives a PCRep that contains an OF object with an objective 
function identifier that the PCC does not recognize. In this 
situation, the PCC behavior is dependent on implementation and 
configuration. The PCC could choose any of the following (or some 
other action): 


— Ignore the OF object and use the computed path. 


— Add the objective function to its view of the PCE’s repertoire for 
inclusion in future computation requests. 


— Discard the PCRep (i.e., the computed path) and send a PCReq to 
another PCE. 


— Discard the PCRep (i.e., the computed path) and send another PCReq 
to the same PCE explicitly requiring the use of some other 
objective function (i.e., by setting the P bit in the OF object). 


4. Objective Functions Definition 
Six objective functions that must be supported by PCEP are listed in 
[RFC4657]. Objective function codes have been assigned by IANA and 
are described below. 
Objective functions are formulated using the following terminology: 
— A network comprises a set of N links (Li, (i=1...N)}. 


— A path P is a list of K links {Lpi, (i=1...K)}. 


— Metric of link L is denoted M(L). This can be the IGP metric, the 
TE metric, or any other metric. 


— The cost of a path P is denoted C(P), where C(P) = sum {M(Lpi), 
(i=1...K)}. 


— Residual bandwidth on link L is denoted r(L). 
— Maximum reservable bandwidth on link L is denoted R(L). 


There are three objective functions that apply to the computation of 
a single path: 


Objective Function Code: 1 


Name: Minimum Cost Path (MCP) 
Description: Find a path P such that C(P) is minimized. 


Le Roux, et al. Standards Track [Page 13] 


RFC 5541 Objective Functions in PCEP June 2009 


Objective Function Code: 2 
Name: Minimum Load Path (MLP) 
Description: Find a path P such that 
( Max {(R(Lpi) - r(Lpi)) / R(Lpi), i=1...K } ) is minimized. 


Objective Function Code: 3 
Name: Maximum residual Bandwidth Path (MBP) 
Description: Find a path P such that 

( Min { r(Lpi), i=1...K } ) is maximized. 


There are three objective functions that apply to a set of path 
computation requests the computation of which is synchronized: 


Objective Function Code: 4 
Name: Minimize aggregate Bandwidth Consumption (MBC) 
Description: Find a set of paths such that 

( Sum (R(Li) - r(Li), i=1...N) ) is minimized. 


Objective Function Code: 5 
Name: Minimize the Load of the most loaded Link (MLL) 
Description: Find a set of paths such that 
( Max { (R(Li) - r(Li)) / R(Li), i=1...N)) is minimized. 


Objective Function Code: 6 
Name: Minimize the Cumulative Cost of a set of paths (MCC) 
Description: Find a set of paths (P1...Pm) such that 

(Sum { C(Pi), i=1...m)) is minimized. 


Other objective functions may be defined in separate documents. 

5. New Metric Types 
Three metric types are defined in PCEP for the METRIC object: TE 
metric, IGP metric, and hop count. These metric types apply to an 


individual request. Here, we define four new metric types that apply 
to a set of synchronized requests: 


Type 4: Aggregate bandwidth consumption. 
Type 5: Load of the most loaded link. 
Type 6: Cumulative IGP cost. 


Type 7: Cumulative TE cost. 
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6. 


6. 


These metrics may be used in a PCReq to indicate a bound (B bit set 
in the METRIC object) or to request the computation of a metric (C 
bit set in the METRIC object), or in a PCRep to indicate a computed 
metric. 


A METRIC object with one of these four types follows the SVEC object 
for which it applies. 


IANA Considerations 
1. PCE Objective Function Sub-Registry 

This document defines a 16-bit PCE objective function identifier to 
be carried within the PCEP OF object, and also defines the PCEP OF- 
List TLV. 

IANA created and now manages the 16-bit "PCE Objective Function" code 
point registry, starting from 1 and continuing through 32767, as 
follows: 

— Objective Function code point value 

— Objective Function name 


- Defining RFC 


The same registry is applicable to the OF object and the OF-List TLV 
that are defined in this document. 


The guidelines (using terms defined in [RFC5226]) for the assignment 
of objective function code point values are as follows: 


— Function code value 0 is reserved. 
— Function code values in the range 1-32767 are assigned as follows: 


o Function code values 1 through 1023 are assigned by IANA using 
the "IETF Review" policy. 


o Function code values 1024 through 32767 are assigned by IANA, 
using the "First Come First Served" policy. 


o Function code values in the range 32768-65535 are for "Private 
Use". 
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Six objective functions are defined in Section 4 of this document and 


have been assigned by IANA: 
Code Point Name Reference 
1 MCP RFC 5541 
2 MLP RFC 5541 
3 MBP RFC 5541 
4 MBC RFC 5541 
5 MLL RFC 5541 
6 MCC RFC 5541 


6.2. PCEP Code Points 

6.2.1. OF Object 
IANA manages the PCEP Objects code point registry (see [RFC5440]). 
This is maintained as the "PCEP Objects" sub-registry of the "Path 


Computation Element Protocol (PCEP) Numbers" registry. 


This document defines a new PCEP object, the OF object, to be carried 
in PCReq and PCRep messages. IANA has made the following allocation: 


Object Name Object Name Reference 
Class Type 
21 OF 1 Objective Function RFC 5541 


6.2.2. OF-List TLV 


IANA manages the PCEP TLV code point registry (see [RFC5440]). This 
is maintained as the "PCEP TLV Type Indicators" sub-registry of the 
"Path Computation Element Protocol (PCEP) Numbers" registry. 


This document defines a new PCEP TLV, the OF-List TLV, to be carried 
in the OPEN object. IANA has made the following allocation: 


Type TLV name References 


4 OF-List RFC 5541 
6.2.3. PCEP Error Values 
IANA maintains a registry of Error-types and Error-values for use in 
PCEP messages. This is maintained as the "PCEP-ERROR Object Error 


Types and Values" sub-registry of the "Path Computation Element 
Protocol (PCEP) Numbers" registry. 
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Two new Error-values are defined for the Error-type "policy 
violation" (type 5): 


Error-type Meaning and error values Reference 
3 Policy violation 
Error-value=3: objective function not RFC 5541 


allowed (request rejected) 


Error-value=4: OF bit of the RP object RFC 5541 
set (request rejected) 


6.2.4. RP Object Flag 


A new flag of the RP object (specified in [RFC5440]) is defined in 
this document. IANA maintains a registry of RP object flags in the 
"RP Object Flag Field" sub-registry of the "Path Computation Element 
Protocol (PCEP) Numbers" registry. 


IANA has made the following allocation: 
Bit Description Reference 
24 Supply OF on response RFC 5541 
6.2.5. Metric Types 
Four new metric types are defined in this document for the METRIC 
object (specified in [RFC5440]). IANA maintains a registry of metric 
types in the "METRIC Object T Field" sub-registry of the "Path 


Computation Element Protocol (PCEP) Numbers" registry. 


IANA has made the following allocations: 


— Type 4: Aggregate bandwidth consumption 
— Type 5: Load of the most loaded link 
— Type 6: Cumulative IGP cost 
— Type 7: Cumulative TE cost 
7. Security Considerations 


PCEP security mechanisms are described in [RFC5440] and are used to 
secure entire PCEP messages. Nothing in this document changes the 
message flows or introduces any new messages, so the security 
mechanisms set out in [RFC5440] continue to be applicable. 
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This document introduces a single new object that may optionally be 
carried on PCEP messages and will be automatically secured using the 
mechanisms described in [RFC5440]. 


If a PCEP message is vulnerable to attack (for example, because the 
security mechanisms are not used), then the OF object could be used 
as part of an attack; however, it is likely that other objects will 
provide far more significant ways of attacking a PCE or PCC in this 
Case. 


8. Manageability Considerations 
8.1. Control of Function and Policy 


It MUST be possible to configure the activation/deactivation of 
objective function discovery in PCEP. 


In addition to the parameters already listed in Section 8.1 of 
[RFC5440], a PCEP implementation SHOULD allow configuring a list of 
authorized objective functions on a PCE. This may apply to any 
session the PCEP speaker participates in, to a specific session with 
a given PCEP peer, or to a specific group of sessions with a specific 
group of PCEP peers. 


Note that it is not mandatory for an implementation to support all 
objective functions defined in Section 4. 


It MUST be possible to configure a default objective function used 
for path computation when a path request is received that requests to 
use an optional objective function. 


8.2. Information and Data Models 


The PCEP MIB Module defined in [PCEP-MIB] could be extended to 
include objective functions. 


8.3. Liveness Detection and Monitoring 
Mechanisms defined in this document do not imply any new liveness 
detection and monitoring requirements in addition to those already 
listed in [RFC5440]. 

8.4. Verify Correct Operations 
Mechanisms defined in this document do not imply any new operation 


verification requirements in addition to those already listed in 
[RFC5440]. 


Le Roux, et al. Standards Track [Page 18] 


RFC 5541 


Objective Functions in PCEP June 2009 


8.5. Requirements On Other Protocols 


Mechanisms defined in this document do not imply any requirements on 
other protocols in addition to those already listed in [RFC5440]. 


8.6. Impact On Network Operations 


Mechanisms defined in this document do not have any impact on network 
operations in addition to those already listed in [RFC5440]. 
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Appendix A. RBNF Code Fragments 


This appendix contains the full set of code fragments defined in this 
document. 


Copyright (c) 2009 IETF Trust and the persons identified as authors 
of the code. All rights reserved. 


Redistribution and use in source and binary forms, with or without 
modification, are permitted provided that the following conditions 
are met: 


o Redistributions of source code must retain the above copyright 
notice, this list of conditions and the following disclaimer. 


o Redistributions in binary form must reproduce the above copyright 
notice, this list of conditions and the following disclaimer in the 
documentation and/or other materials provided with the 
distribution. 


o Neither the name of Internet Society, IETF or IETF Trust, nor the 
names of specific contributors, may be used to endorse or promote 
products derived from this software without specific prior written 
permission. 


THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 


<PCReq Message> ::= <Common Header> 
[<svec-list>] 
<request-list> 


<PCRep Message> ::= <Common Header> 


[<svec-list>] 
<response-list> 
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<svec-list> 


<request-list> 


<request> ::= 


<metric-list> 


<response-list> 


<response> ::= 


<path-list> ::= <path> 


Objective Functions in PCEP 


::= <SVEC> 


[<OF>] 
[<metric-list>] 
[<svec-list>] 


::= <request> [<request-list>] 


<RP> 

<END-POINTS> 
[<LSPA>] 
[<BANDWIDTH>] 
[<metric-list>] 
[<OF>] 

[<RRO> [<BANDWIDTH>] ] 
[<IRO>] 
[<LOAD-BALANCING>] 


::= <METRIC>[<metric-1list>] 


::= <response> [<response-list>] 


<RP> 

[<NO-PATH>] 
[<attribute-list>] 
[<path-list>] 


[<path-list>] 


<path> ::= <ERO> 
<attribute-list> 


<attribute-list> ::= 


et al. 


[<OF>] 

[<LSPA>] 
[<BANDWIDTH>] 
[<metric-list>] 
[<IRO>] 
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